Skip to main content

Architecture Frameworks

A framework is a way of organising architecture work: what to describe, in what order, using which artefacts. Frameworks are not standards. Adopting TOGAF does not make a system interoperable, and adopting OpenHIE does not tell you how to run a governance process.

The two groups below are deliberately separated. A general enterprise architecture framework is not a health standard, and treating one as such — "we are TOGAF-compliant, therefore our health data exchanges" — is a common and expensive error.


Health-specific architecture frameworks​

OpenHIE​

A community-developed reference architecture for national health information exchange: point-of-service systems talking through an interoperability layer to shared registries and domain services. Component-oriented and technology-neutral.

Covered in depth in the OpenHIE section.

WHO Digital Health Platform Handbook​

WHO and ITU guidance on building a national digital health platform: a shared set of services and components that individual health applications reuse instead of each rebuilding identity, terminology and data exchange.

WHO Digital Implementation Investment Guide (DIIG)​

Guidance on planning and costing a digital health investment: linking a health programme need to system requirements, architecture and budget. Useful when the architecture has to survive a finance ministry.

WHO Classification of Digital Health Interventions​

A taxonomy of what digital health systems do, expressed by user category (clients, providers, health system managers, data services). It is the shared vocabulary for describing capability before naming software.

WHO SMART Guidelines​

A method for turning a clinical guideline into computable artefacts — personas, workflows, core data dictionary, decision logic, indicators, FHIR implementation guides. See SMART Guidelines.

Digital public infrastructure for health​

An emerging framing in which health systems build on shared national infrastructure for identity, payments, data exchange and consent rather than health-specific silos. Still consolidating; see digital public infrastructure for what is published versus what is draft.

  • Tier 1 / Tier 4 depending on the specific document

IHE profiles​

Integrating the Healthcare Enterprise publishes profiles — precise constrainings of existing standards for a named use case (patient identity lookup, document sharing, audit). Not a framework in the enterprise-architecture sense, but the closest thing to a catalogue of proven health integration patterns.


General enterprise and software architecture frameworks​

These come from outside health. They are useful; none of them knows what a patient is.

TOGAF​

The Open Group Architecture Framework. Its main contribution is the Architecture Development Method (ADM) — a cycle from architecture vision through business, information systems and technology architecture to implementation governance, plus a content framework describing the artefacts.

Where it helps in health: giving a ministry a repeatable process and a shared document set. Where it does not: it says nothing about terminology, patient identity or clinical safety.

ArchiMate​

A modelling language — notation for business, application and technology layers and the relationships between them. Complements TOGAF rather than competing with it.

Zachman Framework​

A classification schema: six interrogatives (what, how, where, who, when, why) against six stakeholder perspectives. It is a taxonomy for checking completeness of documentation, not a method.

Reference Model of Open Distributed Processing (RM-ODP)​

ISO/IEC 10746. Describes a system from five viewpoints — enterprise, information, computational, engineering, technology. Underlies parts of health informatics standards work, including openEHR's separation of information model from clinical models.

C4 model​

A lightweight approach to software architecture diagrams at four levels of zoom. Practical, and far easier to sustain than formal modelling. See C4 model.

Domain-driven design​

A design approach centred on modelling a bounded domain in the language of its experts. Bounded contexts map unusually well onto health: "patient" means something different in a laboratory system, a billing system and a community health register, and DDD gives you the vocabulary to say so instead of forcing a single canonical model.

  • Tier 3

Architectural styles​

Not frameworks, but the structural choices a solution architecture makes.

StyleFits health whenCosts
Modular monolithSingle organisation, one deployment, small teamScaling limits at very high load
MicroservicesIndependent teams, differing scaling and release needsDistributed failure, operational overhead many ministries cannot staff
Service-oriented architectureA mediating layer already exists (this is essentially OpenHIE)Governance-heavy; ESB can become a bottleneck
Event-driven architectureMany consumers of the same clinical events; surveillanceEventual consistency, ordering and replay must be designed
Cloud-nativeElastic demand, mature ops capabilityData residency and cost predictability
Zero trustMulti-organisation exchange, no trusted network perimeterEvery call needs verifiable identity — see security architecture

A national exchange does not need microservices. Most do need service orientation and some need events. Choose the style from the failure modes you can afford, not from the industry's current fashion.


Choosing between them​

You will normally use more than one, at different altitudes:

Governance and process → TOGAF ADM (or a lighter local equivalent)
Health reference architecture → OpenHIE + WHO Digital Health Platform
Clinical content method → WHO SMART Guidelines
Integration use cases → IHE profiles + FHIR implementation guides
Modelling notation → ArchiMate (formal) or C4 (practical)
Decision record → ADRs

If you can only adopt two things: adopt OpenHIE for the shape of the ecosystem and ADRs for remembering why you chose it.


References​